I2P Tunnels: Garlic Encryption and Unidirectional Information Transfer

Anonymity of I2P network participants is achieved through the use of tunnels. An important feature of I2P is that only the one who created it knows the length of the tunnel, its beginning and end.

Each network node has its own incoming and outgoing tunnels, and by default it also acts as a transit node in the chains of other participants. I2P tunnels are unidirectional—traffic travels in only one direction through each tunnel. In an anonymous network, the user does not have direct access to the subscriber on the other side; he only has information about the starting node in his incoming tunnel. Access to the incoming tunnel of another network participant occurs through an anonymizing chain on its part - through outgoing tunnel. After contact is established, the addressee is informed for a response information about the incoming tunnel of the network participant who contacted him. For information on how nodes find each other's incoming tunnels for the first call, read article about floodphiles.

Chains of several nodes are, if not the most basic, then one of the most important logical parts of I2P. In this article, we will explain the principle of their construction and speculatively prove that the level of anonymity in I2P can be trusted.

Transports

The most popular low-level network protocols today are TCP and UDP. They provide the logic for delivering information between subscribers, but are absolutely not responsible for the privacy of this information - anyone can intercept it along the way. In view of this, for higher-level protocols of application programs there is a need to encrypt information.

I2P uses transport protocols NTCP2 - analogous to TCP, and S.S.U. - analogue of UDP. Essentially, these protocols are cryptographic wrappers of their older brothers. Information within the “invisible Internet” is transmitted using these protocols, which allows you to hide all transmitted information from your home provider.

NTCP2 and SSU not only encrypt information, but also mix in a random amount of extra bytes. "Garbage" leaves no chance for traffic analysis systems, since the size of the packets is random and actually means nothing. After the packet is decrypted at the destination, the idle bytes are simply discarded.

NTCP2 and SSU are tools for secure peer-to-peer communication - direct communication with other routers on the network. At the beginning of this material it is said that anonymity within I2P is achieved through tunnels consisting of several intermediate nodes. In view of this, we will not dwell on how nodes communicate directly with each other, but will move closer to the topic of anonymizing tunnels. Read more about the NTCP2 transport protocol in Russian here.

What is a tunnel

I2P routers, that is, all network nodes, communicate with each other using the I2NP protocol. The actual list of I2NP message types can be seen in source code, or contact official documentation for a detailed explanation.

In fact, I2NP contains an exhaustive set of possible message types necessary for I2P routers to communicate with each other. Note the types whose names contain the word Tunnel. They are the ones that interest us in this article. All user information is transmitted inside tunnels in the form of encrypted blocks from router to router, due to which the original source of information is lost, and its real recipient remains unknown, since it is not known on which of the transit routers the tunnel is interrupted.

There are two main requirements for the logic of tunnels: the anonymity of the tunnel creator in front of its participants, as well as the compatibility of transit nodes of the chain across transports. Briefly about the construction of tunnels it is said in large article about I2P, but now we will delve into the depths of this complex mechanism and once again make sure that the level of anonymity in I2P is unprecedented in its kind.

Analogy of I2P architecture with a regular network

So that the further story does not seem like a dry specification that cannot be understood even after two readings, let us slightly simplify the initial understanding of the I2P network architecture by comparing it with the usual network.

Your device connects to the Internet through a router (router). This can be a home router with a connection via wire or Wi-Fi, or a router from a cellular operator with a connection via 3G/4G/5G networks. The essence does not change from this. Before establishing a logical IP connection with the router, the device exchanges service information at a low level - in the illustration it is designated as “Ethernet frames” (simplified). After establishing a logical connection via IP with the router, you can access computers around the world through it. When you open a website whose server is located in a neighboring city, your traffic passes through many ISP hops, leaving you with only a direct connection to the original router. All intermediate nodes work with you at the level of IP connections - they transmit certain packets of information from point A to point B. Each logical unit along the path of your traffic builds an IP connection with its neighbors also at a lower level, just like you and your home router . It turns out that many computers and routers around the world establish low-level connections with their physical neighbors through wires (or other information transmission media) and, based on this connection, are united in an IP network, where routing with IPv4 or IPv6 addresses, which is familiar to the eye, reigns. The highest level of TCP/IP communication is designated in the illustration as "application". This is the top of the pyramid - user traffic, for example, a browser request to a site using the HTTPS protocol. Lower levels don't know anything about your site and browser, they just work to pass some binary information to the destination, where it will be read in its original form and processed.

I2P runs on top of TCP/IP, but has its own additional structure, which partly replicates a regular network, but with a strong emphasis on privacy and anonymity. An I2P router is a software client on your device that provides all the internal network logic. I2NP messages are the basic tool for communication between I2P routers. Tunnels are an analogue of IP connections that provide direct interaction with other routers and, through them, interaction with nodes with which there is no direct contact. The highest level in the illustration is the "garlic message" - this is user information delivered through tunnels, but only meaningful to the final recipient, who can decipher it.

Messages from the hidden network pass through the regular Internet, but their content can only be understood at a higher level, which requires an I2P router to access. This property is called overlaying. If we go into formalism, the term “deep Internet” in relation to I2P and other hidden networks should sound opposite, for example, “high-level Internet".

Garlic message forming a tunnel

Each I2P router publishes information about itself on floodfills - reference nodes of the network. The full address of the router is called "Router Info", or simply "RI". In addition to information about immediate availability (IP addresses and introducers), as well as some service information, RI contains the public encryption key of the router.

The local network base of an I2P router consists entirely of RI files of other network participants. When a router needs to acquire a tunnel, the first step is to select its future participants. The search for candidates takes place in the local network database (netDb). The declared bandwidth of the router, transport compatibility with neighbors, as well as data from the profile, if available, are taken into account. Profiling means a local chronicle of a router’s interaction with a specific network participant and an assessment of its stability - an unstable router will not be used when building a tunnel.

When candidates are selected, a garlic message is created. If a tunnel is built no longer than four hops, the garlic always contains four cloves, that is, four messages. Otherwise, the garlic consists of eight messages (the number of the maximum possible tunnel length). By default, tunnels are three hops long.

The principle of the garlic message is that each participant in the tunnel receives a complete set of messages (garlic), but can only read one clove intended for him. The garlic message is then transmitted in its entirety according to the instructions received in the clove. The dents are identified by recipients by the first 16 bytes, which are the beginning of the hash of their encryption key. After reading the garlic message, the participant replaces the contents of the clove with his answer. To keep the information secret, it is encrypted with a symmetric key.

The most interesting nuance is that a particular node can only see its clove in the garlic. This prevents you from guessing about other tunnel participants based on their key hashes. Reception is ensured by additional symmetric encryption of the entire garlic. Perhaps someday there will be a separate note about this, but here is the source code for the brave ones:

hop = m_Config->GetLastHop ()->prev;
		while (hop)
		{
			// decrypt records after current hop
			TunnelHopConfig * hop1 = hop->next;
			while (hop1)
			{
				hop->DecryptRecord (records, hop1->recordIndex);
				hop1 = hop1->next;
			}
			hop = hop->prev;
		}

		while (hop)
		{
			// decrypt current hop
			if (hop->recordIndex >= 0 && hop->recordIndex < msg[0])
			{
				if (!hop->DecryptBuildResponseRecord (msg + 1))
					return false;
			}	
			else
			{
				LogPrint (eLogWarning, "Tunnel: hop index ", hop->recordIndex, " is out of range");
				return false;
			}	
			
			// decrypt records before current hop 
			TunnelHopConfig * hop1 = hop->prev;
			while (hop1)
			{
				auto idx = hop1->recordIndex;
				if (idx >= 0 && idx < msg[0])
					hop->DecryptRecord (msg + 1, idx);
				else
					LogPrint (eLogWarning, "Tunnel: hop index ", idx, " is out of range");
				hop1 = hop1->prev;
			}
			hop = hop->prev;
		}

Today, garlic messages come in three types and have corresponding differences.:

• Old. Used when all transit routers in the tunnel use El Gamal encryption. Each message is 528 bytes and contains AES keys: a one-time key for encrypting the response, an initialization vector (IV), an IV encryption key, and a master key used during the life of the tunnel for onion (multi-layer symmetric) encryption.

• Transition. It is used when among transit routers there are nodes with both old El Gamal encryption and new ones with ECIES. Each message is 528 bytes, but for ECIES nodes a different encryption is used for the response: the symmetric encryption key is not directly transmitted, but is calculated using the protocol Noise (Noise_N).

• The new one is “garlic with short messages.” Used when all transit routers use ECIES encryption and have a version no lower than 2.39.0, if we are talking about i2pd, or 1.5.0 for a Java router. Each message is 218 bytes. The cogs do not contain the above keys because in this case they are all computed. AES is used only as the main encryption key for the tunnel, otherwise AEAD/Chaha20/Poly1305 and ChaCha20 algorithms are used. Read more about short garlic messages in specifications.

The uniqueness of the new type of garlic messages lies in its size - a standard four-clove garlic fits into one kilobyte. At the time of publication of this article, all I2P network tunnel messages are divided into one-kilobyte fragments. This is a standard size that is part of the fight against traffic analysis.

Minimum size garlic cloves of 528 bytes require sending three tunnel messages. Despite the obfuscation of traffic, a pattern can hypothetically be identified: three kilobyte messages are standard garlic. If we see a characteristic movement of traffic, it means that the observed user is building a tunnel, or is a transit link in the tunnel of another user. In practice, this threat is something of a fantasy, because the tunnels last only ten minutes, and active nodes constantly participate in more than two thousand transit tunnels. You can imagine how many garlic flies on such a router in just a minute...

When using short messages, all the garlic fits into one tunnel message, so the new garlic completely merges with the rest of the information flow. The spy's last hope for analyzing traffic for three kilobyte messages in a row is lost. But it's not all about paranoia, ladies and gentlemen! One tunnel message instead of three is a factor in increasing the speed of building a tunnel: fewer packets are sent - there is less chance that any of them may be lost, and a smaller amount of information is transmitted faster.

Outgoing and incoming tunnels are built in a similar way:

• When building incoming tunnel, in order to remain incognito, the creator router passes the garlic to the first participant through its outgoing tunnel. The garlic is then passed from node to node and comes back to the tunnel creator. For the last participant in the chain, the creator is no different from the next transit node.

• When building outgoing tunnel, the picture is the opposite: the creator router transmits the garlic directly to the router closest in the chain, which cannot know whether the router that transmitted the garlic is the owner of the garlic, or the same transit node. The clove of the last transit node contains the information to send the garlic back to its creator. Having gone through the entire chain, the garlic is returned to the creator through one of the incoming tunnels.

At startup, the I2P router has no real tunnels, only two tunnels of zero length. When creating the first full-fledged tunnels, the necessary calls do not occur through anonymizing chains of nodes, but directly - through a zero-length tunnel. Due to the fact that this is a rare event and communication through a zero-length tunnel is indistinguishable from normal, this feature is not considered a weak point of the I2P architecture.

Tunnels in a practical network context

In addition to the encryption keys, the garlic cloves contain information about the tunnel numbers (each 4 bytes). One number is the number of the tunnel on which the router will receive messages, and the second number is the number of the tunnel on the next transit node, the address of which is attached, where the current transit router will transmit incoming information.

Garlic messages contain only short addresses of routers that need to transmit garlic further down the chain. The router's address is a SHA256 hash of its full Router Info. If the required router is not in the local database, the transit node needs to contact the floodfill to obtain its full address (RI). When creating garlic, the tunnel creator takes into account the transport compatibility of neighbors with each other, which reduces the likelihood of an unsuccessful attempt to build a tunnel. For example, it is stupid to ask a router without an IPv6 address to contact a network member that only has an IPv6.

The tunnel is considered failed if the response does not come for a long time, or the garlic has returned, but one of the surveyed routers included a refusal to participate in their response (this may be due to the limit on the number of transit tunnels, etc.).

Once a tunnel is created, its life cycle is limited to ten minutes. After this time, all transit nodes stop accepting packets within the old tunnel, and by this time its creator needs to have a new tunnel - it is created shortly before the old one “fades out.” After updating incoming tunnels, if we are talking about a server endpoint that is waiting for calls from other network participants, its LeaseSet is also updated - contact information on floodfills, which includes information about incoming tunnels.

As such, garlic encryption is only used in I2P when creating tunnels. In production mode, the tunnel uses only onion encryption (plus end-to-end encryption from user to user).

Onion encryption is a term that refers to multi-layer symmetric key encryption. In case someone has forgotten or doesn’t know: with symmetric encryption, encryption and decryption are carried out with one key, in contrast to asymmetric algorithms, where encryption occurs with a public key and decryption with a private one. Asymmetric encryption is used in end-to-end encryption.

All tunnels are unidirectional, and transit nodes do not know anything: whether the tunnel is incoming or outgoing, how many participants are in it, and so on. Their task is to encrypt passing information with the received (or mathematically derived) symmetric key and transmit the resulting packet to the next node.

Only end nodes in tunnels take on special roles: for outgoing tunnel, the last node is the Endpoint, and the first node in incoming tunnel - Gateway. Unlike regular "middle" nodes, these two know their place in the chain thanks to special flags they receive in the garlic. The task of Endpoint is to collect kilobyte tunnel messages into a more significant packet (up to 64 kilobytes) and transmit it further according to instructions (into an incoming tunnel, directly to another router, or local information processing). Gateway's task is the opposite: to split received messages into standard one-kilobyte fragments and send these fragments further along incoming tunnel.

When sending packet, router one by one deciphers it with all the keys of transit nodes. This is done so that after each transit node encrypts the information, it appears in its original form. This is a feature of the AES and ChaCha20 symmetric encryption algorithms. It sounds a little complicated, but the point is that encryption and decryption are mirror operations and when decrypting the original information, it is encrypted, but in order to decrypt it later, you need to perform the operation in the opposite direction, that is, encrypt.

At the last router of the outgoing tunnel - Endpoint - the last layer of onion encryption is removed and the information is transmitted to the incoming tunnel of the other side. Even though all onion encryption is removed at this point, user information is not at risk because end-to-end encryption is applied to it in the first place.

In the incoming tunnel, everything is simpler for the uninitiated mind: each transit node adds encryption with its own key (and this is really just a new layer of encryption), then passes the resulting packet to the next node. The final recipient, having removed all onion encryption, decrypts the information with his asymmetric key and verifies the signature, after which the decrypted information is raised to a higher level and given to the external (application) application in its original form.

In general terms, the completed user data transfer scheme looks as shown in the illustration.

With an outgoing tunnel:

• The I2P router receives information from an external local application and packages it into I2NP Data (gzip + service headers);

• End-to-end encryption is carried out with the recipient's key (key from the LeaseSet), it turns out I2NP Garlic;

• Information is prepared for sending through a specific tunnel, a message is generated I2NP Tunnel;

• Traffic is wrapped in transport protocol cryptography;

• Information goes through the physical network to the first (closest) node of the outgoing tunnel.

On incoming tunnel:

• Packets destined for the I2P router arrive over the network;

• Transport protocols are processed and I2NP messages are decrypted;

• The message is I2NP Tunnel - tunnel communication;

• Based on the tunnel identifier, the router understands that this message came from its tunnel. Onion encryption is removed;

• Available message type I2NP Garlic - it is the sender's original message encrypted with the recipient's asymmetric key. The router, being the holder of the address that is the recipient of this message, decrypts it with the private key of the address (in fact, one-time keys and so on are used, but spare our psyche!);

• The output is I2NP Data - user information (gzip + service headers), which is unpacked and sent to an external application.

In the description of the illustration, the emphasis is on user information received from the tunnel, because there are still many service messages and things are different there.

It should be noted that I2NP Garlic - this is a type that just denotes a single-layer end-to-end encrypted message, not a garlic message that is used when building a tunnel. Perhaps it was once planned to use garlic encryption here, but the fate of practical implementation decreed otherwise.

This is a simplified explanation of how I2P tunnels work, but despite all efforts to simplify, the material turned out to be quite difficult to understand. Be that as it may, the most important thing, I believe, is to have at least some understanding of the technology that you decide to rely on to solve important problems.